
REMARKS 

In the May 11, 2001 Office Action, the Examiner rejected claims 37-80, 85-100, 102, 
104, 104-119 and 120-125 under 35 U.S.C. 103 as unpatentable over Fukuma and Waytena and 
rejected claims 82-84 and 101 and 103 as unpatentable over Fukuma, Waytena and Steadham. 
In response thereto, the Applicants have amended claims 39, 41, 44, 51, 58, 64, 67, 69, 70, 71, 
80, and 107. Two claims in the previous amendment were inadvertently numbered "48" in the 
previous amendment. One of these claims has been renumbered claim 126. Claims 37-80 and 
82-126 remain at issue. 

Fukuma 

Fukuma relates to a reservation management system for the efficient space utilization of a 
banquet hall capable of being partitioned into a plurality of areas. The system is an application 
program designed to run on a stand-alone computer such as a personal computer. The 
Applicants believe Figures 1, 3, 4 and 5 of Fukuma are most relevant to the present invention 
and therefore the teachings of Fukuma with respect to these figures will be described in detail 
below. 

Figure 1 of Fukuma illustrates the main software structures of Fukuma' s banquet hall 
reservation system. The main structures include a management table 1 , reservation management 
tables 2, a management table generation unit 7, a management information input unit 6, a 
conflicting area detection unit 4, a vacancy determination unit 3, and a reservation unit 5. 

Figure 3 of Fukuma illustrates all the possible partitions of an exemplary banquet hall 
named "Fuji" that can be sub-divided into three sub-banquet areas ("Fuji 1", "Fuji 2", and "Fuji 
3"). In this example, all the possible combinations of banquet areas are assigned an area code as 
provided in the table below. 



Area Code 


Area 


10 


The entire Fuji banquet hall comprising sub 
areas Fuji 1, Fuji 2, and Fuji 3. 


11 


Sub-area Fuji 1 


12 


Sub-area Fuji 2 


13 


Sub-area Fuji3 


1.4 


Fuji North which includes sub-areas 1 and 2 


1.5 


Fuji South which includes sub-area 2 and 3 
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Figure 4 of Fukuma provides an actual management table 1 for the Fuji banquet hall. In 
this management table, the area codes (10 through 15), the area names (Fuji, Fuji 1, Fuji 2, Fuji 
3, Fuji North and Fuji South), and the conflicting area codes for each area are provided 
respectively. For example, when the "Fuji" area code (10) is reserved, all the area codes (10-15) 
are in conflict and therefore can not be reserved. When "Fuji 2" area code (12) is reserved, 
codes (12, 10, 14 and 15) are in conflict and can not be reserved. However, non-conflicting areas 
Fuji 1 (11) and Fuji 3 (13) can be reserved. For a more detailed discussion of the management 
table 1, see Column 3, lines 57-68 and Column 4, lines 1-8. 

Figure 5 of Fukuma shows a reservation management table 2 for a given day (February 1, 
1995 for the example provided by Fukuma). The reservation management table 2 in this 
example lists all the area codes defined above (10 through 15) for the Fuji banquet area, 
reservation information on an hourly basis (13:00, 14:00 ... 17:00), and the status of each area 
code (10 through 15) for each hour. Banquet areas that are reserved for a given hour are 
designated by either an "M" for meeting or a "D" for dinner. For example, banquet area 1 1 (Fuji 
1) is reserved for a meeting between 14:00 and 16:00 hours. When an area code is not reserved 
for a given hour, it is assigned a conflict number. For example, since none of the area codes are 
reserved at hour 13:00, they are all assigned a conflict number of "0", which means any of these 
area codes are available for booking. However at hour 14:00, area code 10 (Fuji) is assigned a 
conflict number of "3" since it is in conflict with Fuji 1 (11), Fuji 2 (12) and Fuji 3 (13), all of 
which are booked at this time. Similarly, area code 14 (Fuji North) is assigned a conflict number 
of 2 at hour 14:00 since Fuji 1 (11) and Fuji 2 (12) are both reserved at this time. For a more 
detailed discussion of this Figure, see column 7, lines 15-57. 

Prior to operation, the banquet hall provider is first required to determined the 
partitioning of their banquet hall space. The partitioning information and conflict information 
are then entered into the management table 1 as described above with respect to Figure 4. 
During operation when an actual reservation is to be made, the provider is first required to enter 
reservation information (a reservation number, party name, date, banquet area, purpose of use 
and date) through a series of prompts appearing on the computer display (12) of the computer of 
Figure 2. Once the information is entered, the vacancy determination unit (3) checks the 
reservation management table (2) to determine if the requested area code is available for the 
desired date and time and the conflicting area detection unit (4) determines if there is any 
conflict. If the requested area is available and there are no conflicts, then the reservation unit (5) 
enters the reservation into the reservation management table (2) and then updates the table with 
the appropriate conflict information. 
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It must be noted that in no way does Fukuma teach or suggest that the reservation system 
be connected to a network of any kind or that anybody but the banquet hall provider have access 
to the system. Thus in no way does Fukuma contemplate that third parties such as banquet 
hall patrons would have access to the system over a network, 

Waytena 

Waytena provide a system for the remote scheduling of reservations by patrons for 
various attractions or services at a facility such as an amusement park. The system enables the 
patrons to efficiently use their time while at the facility, increasing the number of attractions or 
services visited by the patrons, thereby increasing the enjoyment of the facility. 

The Waytena system includes a plurality of hand-held communication devices (PCDs) 
provided to patrons when they arrive at the facility and a plurality of attraction computers, each 
associated with an attraction at the facility. The PCDs and attraction computers communicate 
with one another over a network to manage the scheduling of reservations. During operation, a 
user enters a request for a reservation for a particular attraction using a PCD. The request is then 
forwarded to the attraction computer over the network. The attraction computer processes the 
request and generates a proposed reservation time that is transmitted back to the PCD if the 
reservation can be accomodated. The patron can then elect to confirm the reservation using the 
PCD. A confirmation results in the patron's reservation time being stored in a "vitual" queue 
within the attraction computer. When a reservation time is approaching, the PDA is designed to 
alert the patron to proceed to the attraction. 

The Waytena system is also designed to operate in conjuction with physical queues as 
well. Thus in a situation where there is both a physical queue and a virtual queue for a given 
attraction, the management and scheduling of patrons using the virtual queue can be adjusted as 
desired to balance the admissions of those in the physical queue. 

It is useful to note that with the Waytena system, those in the physical queue are never 
entered into the reservation system. Rather the physical queue is simply used to adjust the 
admission of those in the virtual queue to an attraction. With reference to Figure 6 and in 
Column 22 line 5, Waytena teaches: 

When physical queue monitor 103 detects changes in the physical 
queue that necessitates changes in virtual queue 210 or when attraction 
information 611 indicates a problem or other change that necessitates such a 
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change, queue updater 212 causes computer 101 to enter state 612. The 
virtual queue 210 is updated to account for the changes. . . . 

More specifically, Waytena teaches that a processor 209 in the attraction computer 
determines a desired interleave ratio for admitting patrons from the physical and virtual queues. 
The interleave ratio is typically base on several factors, including for example, the size of the 
physical queue, staffing, throughput, etc. For more a more detailed discussion of the interleave 
ratio, see Figure 7 and Column 22 line 23 through Column 25 line 4 of Waytena. 



The Rejection 

Claim 37 was rejected by the combination of Fukuma and Waytena. The 
Applicants submit that in constructing the rejection, the Examiner (i) completely misconstrued 
the actual teachings of Fukuma; and (ii) improperly combined the Fukuma and Waytena 
references. Each of these issues are discussed in detail below. 

I. Mis-Construing of Fukuma 

In paragraph 6 of the May 11, 2001 Office Action the Examiner states: 

(a) "... Fukuma teaches an apparatus comprising a 
reservation booking database having a plurality of records 
corresponding to a plurality of time-slots for tables [at] a 
restaurant ..." 

In fact, the database of Fukuma only contains records pertaining to banquet areas. It 
does not contain a plurality of time-slots for tables at a restaurant as the Examiner states; 

(b) "... and a website module configured to create afnj site to 
enable a user to book a table at a banquet area (Fig. 2/10) 

it 

In fact, since the Fukuma system can be accessed only by the banquet hall provider and 
the system is not connected to a network of any kind, there is absolutely no teaching or 
suggestion by Fukuma whatsoever of the website module configured to allow an [Internet] user 
to book a banquet area ; 

(c) "... the website module further comprising a time slot 
display module configured to display one or more available 
time-slots corresponding to one or more available tables at 
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the banquet area's place of business (Fig. 
5/10/11/12/13/14/15) ..." 

Again, Fukuma does not teach a website module or a time-slot display module configured 
to display to an Internet user available tables. This statement by the Examiner is therefore 
completely inaccurate; 

(d) "... and a booking module configured to enable the 
Internet user to book one of the available time slots to 
reserve the corresponding available table (Col 5, lines 16- 
31) in the reservation booking database ... " 

Again, there is absolutely no teaching or suggestion by Fukuma of a booking module that 
allows an Internet user to book an available time-slot at the banquet hall; and 

(e) "... the banquet area maintenance module further 
comprising a reservation booking database having a 
plurality of records, the plurality of records corresponding 
to time slots for the tables at the banquet hall ... " 

The database in Fukuma contains records corresponding to banquet areas, not time-slots 
for individual tables . The Examiner has therefore again misconstrued the teaching of the 
reference. 

To establish a prima facia case of obviousness of a claimed invention, all the claimed 
limitations must be taught or suggested by the prior art. In this case, the Examiner has clearly 
failed to meet this burden since Fukuma does to teach most of the elements of claim 37. 

II. Improper Combination 

In justifying the combination of Fukuma and Waytena, the Examiner states in paragraph 
6 of the Office Action: 

Fukuma teaches the above for banquet halls. Fukuma fails to 
teach Internet communications. Waytena teaches computer 
communication (col. 3, lines 3-7) (col. 6, lines 31-57). It would be 
obvious to one skilled in the art at the time of the invention to 
implement identical methods to restaurants and combine Fukuma 
in view of Waytena to teach the above. The motivation is to apply 
these techniques to the dining industry. 
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The Applicants submit that the proposed combination of Fukuma and Waytena is 
improper. Waytena actually teaches away from the proposed combination and therefore the 
combination is not permissable. Furthermore, even if it were permissible to make the 
combination, not only would it result in a nonsensical system, but it still would not result in the 
present invention as claimed. 

In the proposed combination, it is assumed that the Examiner is relying on the database of 
Fukuma which can be accessed by a facility provider to make reservations with the virtual queue 
of Waytena where patrons can make reservations over a communications network as analogous 
to the Applicants' reservation booking database that can be accessed by both a restaurant and 
Internet users respectively. However Waytena specifically teaches that those in the physical 
queue are never included in the virtual queue. Rather the physical queue is simply used to adjust 
the rate of admission of those in the virtual queue to an attraction. Since Waytena explicitly 
teaches that patrons in the physical queue never are entered into the virtual queue, either by the 
facility provider or patrons themselves, this reference actually teaches away from a system like 
the present invention where patrons using the Internet and a facility provider can both enter 
reservation information into a single database. 

For arguments' sake, even if it were proper to combine Fukuma and Waytena for use 
with a restaurant, the combination would result in a nonsensical system. The proposed 
combination would include (i) the computer system of Fukuma which would allow a restaurant 
provider to make reservations for patrons presumably for tables (as noted above, this feature is 
not specifically taught by Fukuma); and (ii) a separate virtual queue for walk-in patrons at the 
restaurant facility. In this hypothetical system, the restaurant would first provide a walk-in patron 
with a PCD. The patron would then be required to enter their name into a virtual queue to make a 
reservation for a table. Clearly such a system is implausible because a walk-in patron would be 
either seated immediately if a table is available or placed on a wait list until a table becomes 
available. Requiring the patron to make a "reservation" using a PCD in this situation would be 
nonsensical because the purpose of making reservation is to insure a tale is reserved in advance 
for a patron so they do not have to wait. 

Finally the proposed combination still would not result in the present invention as 
provided in claim 37. With Fukuma, the reservation management tables are used for storing 
advanced reservation information for a banquet hall. Waytena teaches the use of a virtual queue 
of patrons seeking to use an attraction who are already physically present at a facility. As noted 
previously, the admission of patrons to an attraction in the virtual queue may be adjusted based 
on the physical queue. But in no way does Waytena teach or suggest that the facility or any other 
party for that matter enter patrons into the virtual queue. Thus the proposed combination actually 
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defines two separate databases. The communication fails to teach a single reservation booking 
database that can be accessed both by an Internet user using a booking module accessible 
through a website module and a restaurant provider using a table reservation module configured 
to enable restaurant provider to make reservations for patrons not using the Internet. 

The Applicants submit that claim 37 is now in a condition for allowance. The Applicants 
further submit that claims 38 -79 and claim 126 are also patentable based on their dependency 
on claim 37, and therefore, the merits of the patentability of these claims are not individually 
addressed herein. However the Applicant's wish to state that they do not agree with the 
Examiner's rejection of these claims and reserve all right to argue the patentability of these 
claims at a later date. 

Similarly, the Applicants submit that independent claims 80, 99, 119, and 120 include 
similar elements as found in claim 37. Specifically each of these claims recites a restaurant 
reservation system or method where both Internet users and a restaurant can make table 
reservations in a reservation booking database. Accordingly for the similar reasons articulated 
above, the Applicants submit that claims 80, 99, 119, and 120 and their dependant claims are all 
in a condition for allowance. Accordingly the merits of the patentability of these claims are not 
individually addressed herein. However the Applicant's wish to state that they do not agree with 
the Examiner's rejection of these claims and reserve all right to argue the patentability of these 
claims at a later date. 
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Applicant believes that all pending claims are allowable and respectfully requests a 
Notice of Allowance for this application from the Examiner. Should the Examiner believe that a 
telephone conference would expedite the prosecution of this application, the undersigned can be 
reached at the telephone number set out below. 

Applicant believes that all pending claims are allowable and respectfully requests a 
Notice of Allowance for this application from the Examiner. Should the Examiner believe that a 
telephone conference would expedite the prosecution of this application, the undersigned can be 
reached at the telephone number set out below. 



Respectfully submitted, 
BEYER WEAVER & THOMAS, LLP 




P.O. Box 778 

Berkeley, CA 94704-0778 

(650) 961-8300 




Marked up Version of the Claims 

39. The apparatus of claim [38] 37, wherein the time-slot display module of the web 
site module further comprises a time-slot search module configured to search and display 
the available time-slots for tables at the restaurant's place of business during a selected 
time period as defined by the Internet user. 

41. The apparatus of claim 37, wherein the booking module of the web site module is 
further configured to require the Internet user to submit personal information over the 
Internet [for the Internet user] to book one of the available time-slots. 

44. The apparatus of claim [43] 41, wherein the web site module further comprises a 
confirmation module configured to generate a confirmation message over the Internet to 
the Internet user after the personal information has been written to the reservation 
booking database of the restaurant to confirm the booking of the selected time-slot. 

[48] 126 . The apparatus of claim 37, wherein the table reservation management 
module is further configured to enable the number of records in the reservation booking 
database for the restaurant to be defined by the restaurant. 

51. The apparatus of claim 50, wherein the restaurant display module is further 
configured to display the time-slot inventory of tables and the time increments for the 
availability of the tables on [the] a computer display. 

58. The apparatus of claim 55, further comprising a restaurant data entry module 
configured to allow the restaurant to write customer information into [the record 
corresponding to the available time-slot] one of the records to book [the] an available 
time-slot in the name of the customer. 

64. The apparatus of claim 37 wherein the web site module further comprises a first 
cancellation module configured to permit the Internet user to cancel over the Internet a 
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previously booked timeslot for a table booked by the Internet user at the restaurant's place 
of business. 

67. The apparatus of claim 37, wherein the restaurant maintenance module further 
comprises a block-out module configured to enable the restaurant to selectively block-out 
time-slots in the [restaurant's time-slot inventory] reservation booking database so 
that the blocked-out time-slots can not be booked. 

69. The apparatus of claim [68] 37, wherein the restaurant maintenance module for 
the restaurant, including the reservation booking database and the table reservation 
management module, are configured to reside on a computer affiliated with the 
restaurant. 

70. The apparatus of claim 69, wherein the restaurant maintenance module is further 
configured to write reservation updates to the restaurant's reservation booking database 
over the Internet to an aggregate database located at [the] a central computing location, 
the aggregate database containing the reservation booking databases for a plurality of 
restaurants affiliated with the web site. 

71. The apparatus of claim 68, wherein the restaurant maintenance module for the 
restaurant, [including] the reservation booking database [database] and the table 
reservation management module, are further configured to reside at the central computing 
location and are accessible by the restaurant over the Internet. 

80. A reservation system comprising: 

a reservation booking database having a plurality of records, the plurality of 
records corresponding to the plurality of time-slots for the tables at [the] a selected 
restaurant; 
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a central computing location configured to an host Internet web site for booking 
reservations [at a plurality of restaurants], the central computing location 
comprising: 

an Internet search module configured to identify [a] the selected restaurant 
in response to a search request submitted by an Internet user to identify the 
selected restaurant [among a plurality of restaurants] affiliated with the web 
site; 

a time-slot display module configured to display one or more available 
time-slots each corresponding to one or more tables at the selected restaurant's 
place of business; and 

a booking module configured to permit the Internet user to book one of the 
available time-slots to reserve the corresponding table in the reservation 
booking database; and 

a local computer located at the selected restaurant, the local computer configured 
to cooperate with the central computing location and including a table reservation 
management module configured to permit the selected restaurant to book time-slots in 
the reservation booking database to reserve tables at the selected restaurant for 
customers not making bookings over the Internet. 

107. The method of claim 99, wherein providing the table reservation management 
module further comprises enabling the first restaurant to manage a selected portion of its 
time-slots [inventory] for table bookings made by Internet users and for customers not 
making reservations over the Internet. 
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